Linux's version of TCP/IP has several utility programs that provide status information
and statistics on network performance. Several debugging utilities are available that
enable a developer or knowledgeable user to trace a network problem. This chapter examines
the basic set of these tools. It begins with a look at the primary configuration files
involved in TCP/IP. Although these files have been discussed in earlier chapters, it is
worth examining them again in closer detail.
Not all of these tools and configuration files will be supplied with every version of
Linux, especially because two variants (BSD and System V) of these utilities are in
general distribution. Check your software package to see which utilities you are supplied
with. If you need a utility that wasn't included, download it from a BBS or FTP site and
hope for no incompatibility problems! Most of the commands and utilities mentioned in this
chapter are not made available to all users, although the superuser can access them all.
Several files are involved in the complete specification of network addresses and
configuration for TCP/IP. Linux allows comments on every line of these configuration
files, as long as they are prefaced by a pound sign (#). Many Linux systems will have
default, empty configuration files with many default entries commented out until the
system administrator removes the comment symbols.
A symbolic name is an alternative to using an IP address. For example, it is much
easier to call a neighboring machine darkstar than 147.23.13.32. Whenever a symbolic name
is used as an address by an application, the TCP/IP software must be able to resolve that
name into a network address (as TCP/IP only uses IP addresses). The ASCII file /etc/hosts
is usually employed, with the symbolic names matched to network addresses. (Note that the
/etc/hosts file does not apply when Yellow Pages (YP), Network Information Services (NIS),
or Domain Name Server (DNS) systems are used. These services use their own configuration
files.)
Linux uses the file /etc/hosts to hold the network addresses and symbolic names, as
well as a connection called the loopback (which is examined later in this chapter in the
section, "Loopback Drivers"). The loopback connection address is usually listed
as the machine name loopback or localhost.
The /etc/hosts file consists of the network address in one column and the symbolic name
in another. Although the network addresses can be specified in decimal, octal, or
hexadecimal format, decimal is the most commonly used form (and use of the others can be
downright confusing). You can specify more than one symbolic name on a line by separating
the names with white space characters (spaces or tabs). The following is a sample Linux
/etc/hosts file:
# network host addresses 127.0.0.1 localhost local merlin_server 157.40.40.12 artemis 157.40.40.2 darkstar 143.10.12.62 big_bob 153.21.63.1 tpci_server tpci_main tpci 191.13.123.4 kitty_cat
Whenever a user or an application specifies a symbolic name, Linux searches the
/etc/hosts file for a matching name and then reads the proper address from the same line.
You can change the contents of the /etc/hosts file at any time, and the changes are
essentially in effect immediately.
Chapter 30, "Configuring TCP/IP," mentioned the
/etc/networks file. This file allows networks to be addressed by a symbolic name, just as
machines are, instead of by their IP address. To resolve the network names, the file
/etc/networks is used to specify symbolic network names. The format of the file provides a
network symbolic name, its network address, and any alias that might be used. A sample
/etc/networks file is shown below:
# local network names tpci 146.1 tpci_network tpci_local bnr 47.80 BNR bnr.ca big_net 123.2.21 unique 89.12323 UNIQUE loopback 127 localhost
The last entry in the file gives the loopback name. The first entry specifies the local
machine name, its network address, and its name variants that may be used by applications.
TCP/IP uses a special number, called a protocol number, to identify the specific
transport protocol a Linux system receives. This allows the TCP/IP software to properly
decode the information coming in. A configuration file called /etc/protocols identifies
all the transport protocols available on the Linux and gives their respective protocol
numbers. All systems have this file, although some entries may be commented out to prevent
unwanted intrusion or abuse.
Usually the /etc/protocols file is not modified by the administrator. Instead, the file
is maintained by the networking software and updated automatically as part of the
installation procedure. The file contains the protocol name, its number, and any alias
that may be used for that protocol. A sample /etc/protocols file is shown below:
# protocols ip 0 IP # internet protocol, pseudo protocol number icmp 1 ICMP # internet control message protocol igmp 2 IGMP # internet group multicast protocol ggp 3 GGP # gateway-gateway protocol tcp 6 TCP # transmission control protocol pup 12 PUP # PARC universal packet protocol udp 17 UDP # user datagram protocol idp 22 IDP # WhatsThis? raw 255 RAW # RAW IP interface
The exact contents of the /etc/protocols file on your system may differ a little from
the file shown above, but the protocol numbers and names are probably very similar. There
may be additional protocols listed, depending on the version of Linux and networking
software.
The last TCP/IP configuration file used on most Linux systems identifies existing
network services. This file is called /etc/services. As with the /etc/protocols file, this
file is not usually modified by an administrator, but is maintained by software when
installed or configured. The exception is when the /etc/services file has services missing
that the application software did not add automatically. In addition, a system
administrator can trim the /etc/services file in order to enhance security, such as when
setting up a firewall to the local area network.
The /etc/services file is in ASCII format, and consists of the service name, a port
number, and the protocol type. The port number and protocol type are separated by a slash.
Any optional service alias names follow. The following is a short extract from a sample
/etc/services file (the file is usually quite lengthy):
# network services echo 7/tcp echo 7/udp discard 9/tcp sink null discard 9/udp sink null ftp 21/tcp telnet 23/tcp smtp 25/tcp mail mailx tftp 69/udp # specific services login 513/tcp who 513/udp whod
Most /etc/services files will have many more lines, because a wide number of TCP/IP
services are supported by most versions of Linux. Most Linux systems are not used as
firewalls to the Internet or between LANs, so administrators of most Linux machines will
never have to worry about the contents of this file. On the other hand, if your machine is
going to act as a firewall or you are very worried about security, you may want to
manually modify the /etc/services file.
The loopback driver is one of the most fundamental and oft-used diagnostic tools
available to a system administrator. The loopback driver acts like a virtual circuit out
of and back into the host machine. All outgoing information is immediately rerouted back
to an input. You can use the loopback driver to test your machine's circuits by
eliminating any external influences (including the network card, the network itself,
gateways, or remote machines). With the loopback driver, you can ensure that the local
machine is working properly and that any problems are from further out on the network.
Loopback drivers are embedded as part of the Linux operating system kernel.
Because TCP/IP requires a destination IP address in order to send data, a loopback
driver is set up as a special network address with the IP address 127.0.0.1. The loopback
driver entries are always made in the /etc/hosts file, as shown below:
loopback 127 localhost
The loopback driver is also known as the localhost, and you can use either name. If the
loopback driver doesn't already exist on your machine, you must create it with the
ifconfig command. For more information, see Chapter 30,
"Configuring TCP/IP."
With the ifconfig program, you can activate and deactivate network interfaces, as well
as configure them. Access to the ifconfig program is generally restricted to the
superuser. Many options are available with ifconfig, most of which system administrators
never use. Most of the time, you will use ifconfig only to enable an interface, as shown
in Chapter 30, "Configuring TCP/IP."
The format of ifconfig commands always follow the same syntax. The syntax is
ifconfig interface [address [parms]]
where interface is the name of the interface, address is the (optional) IP address or
symbolic name to be assigned to the interface (which is verified in /etc/hosts or
/etc/networks), and parameters is one of a list of optional arguments for the address.
When used with only the name of an interface, ifconfig returns information about the
current state of the interface, as shown in the following code. In this example, a query
of both an Ethernet card and the loopback driver is performed. The status flags of the
interface are followed by the Internet address, broadcast address, and optionally provides
a network mask which defines the Internet address used for address comparison when
routing. Your output may be different, but ifconfig should always display information
about the interface (unless one has not been defined).
$ ifconfig eth0
eth0 Link encap 10Mps: Ethernet Hwaddr
inet addr 147.123.20.1 Bcast 147.123.1.255 Mask 255.255.255.0
UP BROADCAST RUNNING MTU 1500 Metric 1
RX packets:0 errors:0 dropped:0 overruns:0
TX packets:0 errors:0 dropped:0 overruns:0
$ ifconfig lo
lo Link encap: Local Loopback
inet addr 127.0.0.1 Bcast {NONE SET] Mask 255.0.0.0
UP BROADCAST LOOPBACK RUNNING MTU 2000 Metric 1
RX packets:0 errors:0 dropped:0 overruns:0
TX packets:0 errors:0 dropped:0 overruns:0
The output from the ifconfig command shows the interface, any characteristics it has
assigned to it, broadcast addresses, and network masks. MTU stands for maximum transfer
unit. The Maximum Transfer Unit size is usually set to the maximum value the interface
type will support (1500 for Ethernet networks). Some operating systems use the Metric
field to compute the cost of any particular route, although Linux doesn't use this field.
The RX and TX lines show how many packets of data have been received and transmitted
respectively, both in total and those with errors, since the interface started in the
current session.
As mentioned earlier, ifconfig accepts a long list of optional arguments to tailor the
behavior of the interfaces. The following arguments are available with most versions of
Linux:
| allmulti | This argument sets multicast mode. It is not currently supported by Linux. |
| -allmulti | This argument turns off multicast mode. |
| arp | Use this argument to enable Address Resolution Protocol to detect physical address on network machines. This argument is set to on by default. |
| -arp | This argument disables ARP. It sets characteristic flag NOARP. |
| broadcast | Followed by the broadcast address of the network, this argument sets the address used to address all machines on the network. This argument is used if the broadcast address is different than the normal address calculated by TCP/IP based on the Class type of the network. |
| down | This argument makes the interface unusable by the IP software until taken up again. |
| metric | This argument sets the metric value for the interface. Although Linux doesn't use this argument, it is included for compatibility with older TCP/IP implementations. |
| mtu | Followed by a value in bytes, this argument sets the Maximum Transmission Unit size (the number of octets the interface can handle in one datagram). System defaults are usually accurate. (Ethernet defaults to 1500, SLIP to 296.) |
| netmask | Followed by a mask value, this argument sets the subnet mask. |
| pointopoint | This argument is used for point-to-point IP (PLIP) interfaces connecting two machines through the parallel port |
| promisc | This argument sets the interface to promiscuous mode (receives all packets, whether they're for that machine's IP address or not). Used for analyzing network traffic, this argument sets the characteristic flag PROMISC. |
| -promisc | This argument turns off promiscuous mode. |
| up | Implied when an address is given, the up argument makes the interface available to the IP software. When active, the interface has the characteristics of UP and RUNNING. |
You can use most of these arguments when you use the ifconfig command, although most
are not necessary for a well-configured network.
When a networked Linux machine is started, it activates TCP/IP and immediately accepts
connections at its ports, spawning a process for each. To control the processes better,
the inetd program was developed to handle the port connections itself, offloading that
task from the server. The primary difference is that inetd creates a process for each
connection that is established, whereas the server would create a process for each port
(which leads to many unused processes). On many systems, some of the test programs and
status information utilities are run through inetd.
The inetd program uses the configuration file /etc/inetd.conf. The following code is an
extract of a sample /etc/inetd.conf file. The first column shows the service name (which
corresponds to an entry in the services file such as /etc/services), the socket type
(stream, raw, or datagram), protocol name, whether inetd can accept further connections at
the same port immediately (nowait) or must wait for the server to finish (wait), the login
that owns the service, the server program name, and any optional parameters needed for the
server program.
#inetd.conf ftp stream tcp nowait NOLUID /etc/ftpd ftpd telnet stream tcp nowait NOLUID /etc/telnetd telnetd shell stream tcp nowait NOLUID /etc/rshd rshd login stream tcp nowait NOLUID /etc/rlogind rlogind exec stream tcp nowait NOLUID /etc/rexecd rexecd finger stream tcp nowait nouser /etc/fingerd fingerd comsat dgram udp wait root /etc/comsat comsat ntalk dgram udp wait root /etc/talkd talkd echo stream tcp nowait root internal discard stream tcp nowait root internal chargen stream tcp nowait root internal daytime stream tcp nowait root internal time stream tcp nowait root internal echo dgram udp wait root internal discard dgram udp wait root internal chargen dgram udp wait root internal daytime dgram udp wait root internal time dgram udp wait root internal
The actual /etc/inetd.conf file may be much longer, but the extract above shows the
general format of the file. The /etc/inetd.conf file is read when the server is booted and
every time a hangup signal is received from an application. This allows dynamic changes to
the file, as any modifications would be read and registered on the next file read.
The netstat program provides comprehensive information about the local system and its
TCP/IP system. Administrators commonly use this program to quickly diagnose a problem with
TCP/IP. Although netstat's format and specific information differ with the version of
Linux, netstat usually supplies the following important summaries, each of which is
covered in more detail later:
With some later versions, information about the interprocess communications and other
protocol stacks may be appended as well. The information to be displayed can usually be
toggled with a command line option. The following are valid options for most versions of
netstat are:
| -a | Displayd information about all interfaces |
| -c | Displays continuously, updating every few seconds |
| -i | Displays information about the interfaces |
| -n | Displays IP addresses instead of symbolic names |
| -o | Displays additional information about timer states, expiration times, and backoff times |
| -r | Displays information about the kernel routing table |
| -t | Displays information about TCP sockets only |
| -u | Displays information about UDP sockets only |
| -v | Displays version information |
| -w | Displays information about raw sockets only |
| -x | Displays information about sockets |
The output from a typical Linux installation that uses the netstat command is shown in
the next few sections, which discuss netstat and its output in more detail. As already
mentioned, the output and meaning may be different with other versions, but the general
purpose of the diagnostic tool remains the same.
The netstat command with no options provides information on all active communications
end points. To display information about a particular type of end point, use the letter of
the type from the following list:
| -a | All connections |
| -t | TCP connections only |
| -u | UDP connections only |
| -w | RAW connections only |
| -x | Socket connections only |
To display all end points that are waiting for a connection (in addition to the sockets
specified by one of the above flags), netstat uses the -a option. The -a option by itself
will display all sockets.
The output is formatted into columns showing the protocol (Proto), the amount of data
in the receive and send queues (Recv-Q and Send-Q), the local and remote addresses, and
the current state of the connection. The following is a truncated sample output:
$ netstat -ta Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) ip 0 0 *.* *.* tcp 0 2124 tpci.login merlin.1034 ESTABL. tcp 0 0 tpci.1034 prudie.login ESTABL. tcp 11212 0 tpci.1035 treijs.1036 ESTABL. tcp 0 0 tpci.1021 reboc.1024 TIME_WAIT tcp 0 0 *.1028 *.* LISTEN tcp 0 0 *.* *.* CLOSED tcp 0 0 *.6000 *.* LISTEN tcp 0 0 *.listen *.* LISTEN tcp 0 0 *.1024 *.* LISTEN tcp 0 0 *.sunrpc *.* LISTEN tcp 0 0 *.smtp *.* LISTEN tcp 0 0 *.time *.* LISTEN tcp 0 0 *.echo *.* LISTEN tcp 0 0 *.finger *.* LISTEN tcp 0 0 *.exec *.* LISTEN tcp 0 0 *.telnet *.* LISTEN tcp 0 0 *.ftp *.* LISTEN tcp 0 0 *.* *.* CLOSED
In the preceding sample extract, three TCP connections are active, as identified by the
state ESTABL. One has data being sent (as shown in the Send-Q column), while another has
incoming data in the queue. The network names and port numbers of the connection ends is
shown whenever possible. An asterisk means no end point has yet been associated with that
address.
One connection is waiting to be hung up, identified by TIME_WAIT in the state column.
After thirty seconds, these sessions are terminated and the connection freed. Any row with
LISTEN as the state has no connection at the moment, and is waiting.
You can use the -a option by itself to display a complete list of all connections. The
output, which is quite lengthy, looks the same, but includes all connections (active and
passive):
$ netstat -a Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) ip 0 0 *.* *.* tcp 0 2124 tpci.login merlin.1034 ESTABL. tcp 0 0 tpci.1034 prudie.login ESTABL. tcp 11212 0 tpci.1035 treijs.1036 ESTABL. tcp 0 0 tpci.1021 reboc.1024 TIME_WAIT tcp 0 0 *.1028 *.* LISTEN tcp 0 0 *.* *.* CLOSED tcp 0 0 *.6000 *.* LISTEN tcp 0 0 *.listen *.* LISTEN tcp 0 0 *.1024 *.* LISTEN tcp 0 0 *.sunrpc *.* LISTEN tcp 0 0 *.smtp *.* LISTEN tcp 0 0 *.time *.* LISTEN tcp 0 0 *.echo *.* LISTEN tcp 0 0 *.finger *.* LISTEN tcp 0 0 *.exec *.* LISTEN tcp 0 0 *.telnet *.* LISTEN tcp 0 0 *.ftp *.* LISTEN tcp 0 0 *.* *.* CLOSED udp 0 0 *.60000 *.* udp 0 0 *.177 *.* udp 0 0 *.1039 *.* udp 0 0 *.1038 *.* udp 0 0 localhost.1036 localhost.syslog udp 0 0 *.1034 *.* udp 0 0 *.* *.* udp 0 0 *.1027 *.* udp 0 0 *.1026 *.* udp 0 0 *.sunrpc *.* udp 0 0 *.1025 *.* udp 0 0 *.time *.* udp 0 0 *.daytime *.* udp 0 0 *.chargen *.* udp 0 0 *.route *.* udp 0 0 *.* *.*
The output is similar to that for the -ta options shown previously, except the UDP
(User Datagram Protocol) connections have been added. UDP sessions have no state column
because they do not have an end-to-end connection.
The behavior of the network interface (such as the network interface card) can be shown
by using the -i option to the netstat command. This information quickly shows you whether
major problems exist with the network connection.
The netstat -i command displays the name of the interface (Iface), the maximum number
of characters a packet can contain (MTU), the metric value (not used with Linux), and a
set of columns for the number of packets received without problem (RX-OK), received with
errors (RX-ERR), received but dropped (RX-DRP), and received but lost due to overrun
(RX-OVR). The transmitted packets have similar columns. The last column contains a list of
flags set for the interface. The following is a sample output from a netstat -i command:
$ netstat -i Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags lo 2000 0 231 0 0 0 231 0 0 0 BLRU eth0 1500 0 1230 2 9 12 1421 3 2 1 BRU
This extract shows two interfaces in use: an Ethernet device (/dev/eth0) and the
loopback driver (lo0). In this case, you can see the Ethernet interface has had a few bad
packet receptions. This is normal because of the nature of the Ethernet system, although
if the numbers become too high a percentage of the total packets sent, you should start
diagnostic methods to find out why.
You can obtain more specific information about one interface by using the -i option
with a device name and a time interval, specified in seconds, such as netstat -i eth0 30,
to obtain specific information about the behavior of the "eth0" (Ethernet)
interface over the last thirty seconds. For example, the output below shows the activity
of the Ethernet interface for the last 30 seconds:
$ netstat -i eth0 30 Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags eth0 1500 0 2341 3 5 112 2111 5 8 8 BRU
The flags column in the netstat output matches the types of flags you saw with the
ifconfig command. The meaning of the flags is shown in the following list:
| B | Broadcast address has been set |
| L | Loopback driver |
| M | Promiscuous mode |
| N | Trailers are avoided |
| O | ARP turned off |
| P | Point-to-point connection |
| R | Running |
| U | Interface is up |
As you can see in the extracts from the previous commands above, several of the flags
can be combined into one block.
Versions of netstat that are based on System V UNIX (instead of BSD UNIX) allow
displays of data buffer statistics. Information about the TCP/IP data buffers can be
obtained with the netstat command's -m option. Monitoring the behavior of the buffers is
important, because they directly impact the performance of TCP/IP. The output of the
netstat -m command differs depending on the version of Linux networking software in use,
reflecting the different implementations of the TCP/IP code.
The netstat -m command output is shown below. In this version, entries are provided for
the streamhead, queue, message descriptor table (mblks), data descriptor table (dblks),
and the different classes of data descriptor tables. The columns show the number of blocks
currently allocated (alloc), the number of columns free (free), the total number of blocks
in use (total), the maximum number of blocks that were in use at one time (max), and the
number of times a block was not available (fail).
$ netstat -m streams allocation: config alloc free total max fail streams 292 79 213 233 80 0 queues 1424 362 1062 516 368 0 mblks 5067 196 4871 3957 206 0 dblks 4054 196 3858 3957 206 0 class 0, 4 bytes 652 50 602 489 53 0 class 1, 16 bytes 652 2 650 408 4 0 class 2, 64 bytes 768 6 762 2720 14 0 class 3, 128 bytes 872 105 767 226 107 0 class 4, 256 bytes 548 21 527 36 22 0 class 5, 512 bytes 324 12 312 32 13 0 class 6, 1024 bytes 107 0 107 1 1 0 class 7, 2048 bytes 90 0 90 7 1 0 class 8, 4096 bytes 41 0 41 38 1 0 total configured streams memory: 1166.73KB streams memory in use: 44.78KB maximum streams memory used: 58.57KB
The failure column is important, and tt should always show zeros. If a larger number
appears there, it means that the particular resource in question has been overtaxed and
the number of blocks assigned to that resource should be increased (followed by a kernel
rebuild and a reboot of the system to effect the changes).
Routing tables are continually updated to reflect connections to other machines. To
obtain information about the routing tables, the netstat -r and -rs options are used (the
latter generates statistics about the routing tables).
The output from netstat -r and netstat -rs commands are shown below. The columns show
the destination machine, the address of the gateway to be used (an asterisk means no
gateway to be used), the Genmask which specifies the generality of the route (which IP
addresses can be matched to it), a set of flags, a metric value (not used), a reference
counter (Refs) that specifies how many active connections may use that
route simultaneously, the number of packets that have been sent over the route (Use), and
the interface name.
$ netstat -r Kernel routing table Destination Gateway Genmask Flags Metric Ref Use Iface loopback * 255.0.0.0 U 0 0 21 lo big_system * 123.23.1.0 UGN 1 0 321 eth0 small_system * 165.213.14.0 UN 1 0 1213 eth0
The flags are used to show different characteristics of the route. The following are
valid flags:
| D | Generated by ICMP |
| G | Uses a Gateway |
| H | Only a single host can be reached this way (such as loopback) |
| M | Modified by ICMP |
| U | Interface is up |
You can combine the -s and -rs options with the -n option to display the IP addresses
of the entries in the routing table, instead of the symbolic name (as shown above). The
layout and information displayed by the netstat command will vary depending on the Linux
implementations, as in the following example:
$ netstat -nr Kernel routing table Destination Gateway Genmask Flags Metric Ref Use Iface 127.0.0.1 * 255.0.0.0 U 0 0 21 lo 123.23.1.2 * 123.23.1.0 UGN 1 0 321 eth0 165.213.14.1m * 165.213.14.0 UN 1 0 1213 eth0
This flag saves you from having to figure out the symbolic to IP address translations
yourself.
System V-based versions of netstat (as opposed to most Linux BSD-based versions) enable
you to display protocol statistics. Statistics about the overall behavior of network
protocols can be obtained with the netstat -s command. This usually provides summaries for
IP (Internet Protocol), ICMP (Internet Control Message Protocol), TCP (Transmission
Control Protocol), and UDP (User Datagram Protocol). The output from this command is
useful for determining where an error in a received packet was located, and then leading
the user to try to isolate whether that error was due to a software or network problem.
Issuing the netstat -s command provides a verbose output, as shown in the following
example:
$ netstat -s ip: 183309 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with header length < data size 0 with data length < header length 0 with unknown protocol 13477 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled 0 packets forwarded 0 packets not forwardable 75 no routes 0 redirects sent 0 system errors during input 309 packets delivered 309 total packets sent 0 system errors during output 0 packets fragmented 0 packets not fragmentable 0 fragments created icmp: 1768 calls to icmp_error 0 errors not generated because old message was icmp Output histogram: destination unreachable: 136 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Input histogram: destination unreachable: 68 0 message responses generated 68 messages received 68 messages sent 0 system errors during output tcp: 9019 packets sent 6464 data packets (1137192 bytes) 4 data packets (4218 bytes) retransmitted 1670 ack-only packets (918 delayed) 0 URG only packets 0 window probe packets 163 window update packets 718 control packets 24 resets 9693 packets received 4927 acks (for 74637 bytes) 37 duplicate acks 0 acks for unsent data 5333 packets (1405271 bytes) received in-sequence 23 completely duplicate packets (28534 bytes) 0 packets with some dup. data (0 bytes duped) 38 out-of-order packets (5876 bytes) 0 packets (0 bytes) of data after window 0 window probes 134 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 system errors encountered during processing 224 connection requests 130 connection accepts 687 connections established (including accepts) 655 connections closed (including 0 drops) 24 embryonic connections dropped 0 failed connect and accept requests 0 resets received while established 5519 segments updated rtt (of 5624 attempts) 5 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 0 connections lingered 0 linger timers expired 0 linger timers cancelled 0 linger timers aborted by signal udp: 0 incomplete headers 0 bad data length fields 0 bad checksums 68 bad ports 125 input packets delivered 0 system errors during input 268 packets sent
Again, the exact layout of the output changes depending on the version of the
networking code. However, you can use the basic information with all formats.
Chapter 30, "Configuring TCP/IP," showed you how to
use the ping command to check whether interfaces were functioning correctly. You use the
ping (Packet Internet Groper) utility to query another system to ensure a connection is
still active.
The ping program operates by sending out an Internet Control Message Protocol (ICMP)
echo request. If the destination machine's IP software receives the ICMP request, it will
issue an echo-reply back immediately. The sending machine will continue to send an echo
request until the ping program is terminated with a break sequence (Ctrl-c or DEL in
UNIX). After termination, ping displays a set of statistics. The following is a sample
ping session:
$ ping merlin PING merlin: 64 data bytes 64 bytes from 142.12.130.12: icmp_seq=0. time=20. ms 64 bytes from 142.12.130.12: icmp_seq=1. time=10. ms 64 bytes from 142.12.130.12: icmp_seq=2. time=10. ms 64 bytes from 142.12.130.12: icmp_seq=3. time=20. ms 64 bytes from 142.12.130.12: icmp_seq=4. time=10. ms 64 bytes from 142.12.130.12: icmp_seq=5. time=10. ms 64 bytes from 142.12.130.12: icmp_seq=6. time=10. ms --- merling PING Statistics --- 7 packets transmitted, 7 packets received, 0% packet loss round-trip (ms) min/avg/max = 10/12/20
An alternate method to invoke ping is to provide the number of times you want it to
query the remote. Also, you could provide a packet length as a test. The following command
instructs ping to use 256 data byte packets and to try five times:
$ ping merlin 256 5 PING merlin: 256 data bytes 256 bytes from 142.12.130.12: icmp_seq=0. time=20. ms 256 bytes from 142.12.130.12: icmp_seq=1. time=10. ms 256 bytes from 142.12.130.12: icmp_seq=2. time=10. ms 256 bytes from 142.12.130.12: icmp_seq=3. time=20. ms 256 bytes from 142.12.130.12: icmp_seq=4. time=10. ms --- merling PING Statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip (ms) min/avg/max = 10/13/20
Using ping to send large packets is one method of determining the network's behavior
with large packet sizes, especially when fragmentation must occur. The ping program is
also useful for monitoring response times of the network, by observing the reply time on
packets sent as the network load (or the machine load) changes. This information can be
very useful in optimization of TCP/IP. Some older implementations of ping simply reply
with a message that the system at the other end is active (the message is of the form
"X is alive"). To obtain the verbose messages shown previously, you must use the
-s option.
The ping program is useful for diagnostics because it tells you whether the TCP/IP
software is functioning correctly, whether a local network device can be addressed
(validating its address), and whether a remote machine can be accessed (again validating
the address and testing the routing). It also verifies the software on the remote machine.
The arp program manages entries in the system's Address Resolution Protocol (ARP)
tables. ARP provides the link between the IP address and the underlying physical address.
With arp, you can create, modify, or delete entries in the ARP table. Typically, this will
have to be performed whenever a machine's network address changes (either because of a
change in the network hardware or because of a physical move).
To use the arp program, you need to follow one of the following formats:
arp [-v] [-t type] -a [hostname] arp [-v] [-t type] -s hostname hwaddress arp [-v] -d hostname [hostname ...]
When specifying a hostname you can use either a symbolic name or the IP address.
To display the entry for a host or IP address, use the first format shown above. If you
do not give a hostname, all hosts are shown. For example, to check the ARP entry for the
remote machine darkstar, issue the following command:
$ arp -a darkstar IP address HW type HW address 147.12.32.1 10Mbps Ethernet 00:00:C0:5A:3F:C2
This command shows that the machine darkstar has the IP address 147.12.32.1, and is
reached through a 10Mbps Ethernet connection. You can slightly alter the output by using
the -t option with a specific type of interface. Valid values are ax25 (AMPR AX.25
networks), ether (10Mbps Ethernet), and pronet (IEEE 802.5 Token Ring). For example, to
show all the Ethernet connections only, use the following command:
arp -t ether -a
To add an entry to the ARP tables, use the second format of the command shown earlier,
using the -s option. When adding an entry, the hwaddress refers to the hardware address of
the adapter (usually six sets of hexadecimal digits separated by colons). For example, to
add an entry for the remote system big_cat, you would issue the command
arp -s big_cat 00:00:c0:10:A1
where the hardware address of the network card is as shown.
Finally, the last format of the arp command shown above is used to delete entries from
the ARP table. This format may be necessary when you have incorrectly added an entry to
the table or the network has changed. To delete the entry for the machine x-wing, issue
this command:
arp -d x-wing
Several other options are valid with many versions of arp, but you will probably never
have to use the arp command at all (let alone these more obscure options). If you need
more information, the man pages include a list of all valid options and their functions.
Most Linux systems have a utility called traceroute available that sends a series of
UDP (User Datagram Protocol) datagrams to a target machine. The datagrams are constructed
slightly differently depending on their location in the stream sent to the remote machine.
The first three datagrams have a field called Time to Live (TTL) set to a value of one,
meaning that the first time a router encounters the message it is returned with an expiry
message (the datagram has been discarded). The next three messages have the TTL field set
to two, three, four, and so on so that each router the messages pass through will return
an expiry message until the destination machine is successfully reached.
The traceroute output shows the round trip time of each message (which is useful for
identifying bottlenecks in the network) and the efficiency of the routing algorithms
(through a number of routers which may not be the best route). The following is sample
output from a traceroute command:
$ traceroute black.cat.com 1 TPCI.COM (127.01.13.12) 51ms 3ms 4ms 2 BEAST.COM (143.23.1.23) 60ms 5ms 7ms 3 bills_machine.com (121.22.56.1) 121ms 12ms 12ms 4 SuperGateway.com (130.12.14.2) 75ms 13ms 10ms 5 black.cat.com (122.13.2.12) 45ms 4ms 6ms
This output shows each router the messages were received by until the destination
machine was reached. The traceroute command has many options to tailor its behavior, which
are all explained in the man page. The traceroute command is usually used by system or
network administrators when there are delivery problems with messages or network behavior
seems very slow. Because most Linux systems are on small local area networks or are
stand-alone, you may never have to use traceroute.
For RPC (Remote Procedure Call) services, a utility called rpcinfo can determine which
RPC services are currently active on the local machine or any remote system that supports
RPC. The options supported by rpcinfo vary with the implementation, but all
implementations allow flags to decide which type of service to check.
For example, the -p option displays the local portmapper. The following example shows
the options supported by the Slackware Linux version of rpcinfo, as well as the output for
the portmapper:
merlin:~# rpcinfo Usage: rpcinfo [ -n portnum ] -u host prognum [ versnum ] rpcinfo [ -n portnum ] -t host prognum [ versnum ] rpcinfo -p [ host ] rpcinfo -b prognum versnum rpcinfo -d prognum versnum merlin:~# rpcinfo -p program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100005 1 udp 650 mountd 100005 1 tcp 652 mountd 100003 2 udp 2049 nfs 100003 2 tcp 2049 nfs
As with the traceroute command, most system administrators will never need to use
rpcinfo. If you are a network programmer or a network administrator, they may be handy
utilities to know about, though.
This chapter has shown you the basic administration programs used with TCP/IP, as well as the configuration files that are necessary to use TCP/IP properly. Knowing the tools available and the type of diagnostics that can be produced is useful to better understanding TCP/IP and especially handy when you are having a problem.
